Added support for lifecycle.started option#4672
Conversation
|
Commit: a79625c
25 interesting tests: 8 FAIL, 7 KNOWN, 7 SKIP, 1 BUG, 1 flaky, 1 RECOVERED
Top 20 slowest tests (at least 2 minutes):
|
| App: input.App, | ||
| SourceCodePath: input.SourceCodePath, | ||
| Config: input.Config, | ||
| GitSource: input.GitSource, |
There was a problem hiding this comment.
Why do we need all these new fields to support 'started' state?
Also, why don't we track 'bool started' here?
There was a problem hiding this comment.
Why do we need all these new fields to support 'started' state?
While working on the feature I realised we don;t track these field in the state correctly, so fixed it. Started should be here as well indeed, will add it
There was a problem hiding this comment.
While working on the feature I realised we don;t track these field in the state correctly, so fixed it.
Interesting, is that possible to have a regression test for this + fix in a separate PR? I wonder how our test suite missed this omission, is that because none of our configs use that fields?
Can we add a new invariant test config or extend existing one with these fields? That should take care of the rest.
There was a problem hiding this comment.
I need to keep these fields here because I introduce AppState and Started field, so I would prefer not to make multiple PRs out of it.
But I will add a regression test and investigate why we missed it in a separate PR, we have tests that included all of these fields including invariant test with SourceCodePath field in
There was a problem hiding this comment.
But I will add a regression test and investigate why we missed it in a separate PR, we have tests that included all of these fields including invariant test with SourceCodePath field in
okay, let's review this first. It still seems that AppState/SourceCodePath/Config/GitSource change is big enough to deserve its own PR / changelog entry but let's see the root cause first.
| Ignore = [".databricks"] | ||
|
|
||
| [EnvMatrix] | ||
| DATABRICKS_BUNDLE_ENGINE = ["direct"] |
There was a problem hiding this comment.
Why not run this test on terraform as well, to assert the error?
| Ignore = [".databricks", "databricks.yml"] | ||
|
|
||
| [EnvMatrix] | ||
| DATABRICKS_BUNDLE_ENGINE = ["direct"] |
There was a problem hiding this comment.
Same q - why not run this on terraform to see what kind of error we get?
| } | ||
|
|
||
| func (m *validateLifecycleStarted) Apply(_ context.Context, b *bundle.Bundle) diag.Diagnostics { | ||
| // lifecycle.started is a direct-mode-only feature; ignore it in other modes. |
There was a problem hiding this comment.
Why not reject it with error? Otherwise people might add / copy-paste config thinking it'll do something but it'll be quietly ignored.
|
|
||
| func boolPtr(b bool) *bool { return &b } | ||
|
|
||
| func TestValidateLifecycleStarted_UnsupportedResource(t *testing.T) { |
There was a problem hiding this comment.
Do these tests add any coverage on top of acceptance tests?
We've discussed some time that it's good not to add any new mutator unit tests because that complicates mutator refactoring and is often misleading due to not taking into account previous and subsequent mutators.
(We can/should add unit tests for local functions that don't work on the whole bundle).
| App: input.App, | ||
| SourceCodePath: input.SourceCodePath, | ||
| Config: input.Config, | ||
| GitSource: input.GitSource, |
There was a problem hiding this comment.
But I will add a regression test and investigate why we missed it in a separate PR, we have tests that included all of these fields including invariant test with SourceCodePath field in
okay, let's review this first. It still seems that AppState/SourceCodePath/Config/GitSource change is big enough to deserve its own PR / changelog entry but let's see the root cause first.
| // With lifecycle.started=true, ensure the app compute is running and deploy the latest code. | ||
| if config.Started { | ||
| // Start compute if it is stopped (mirrors bundle run behavior). | ||
| app, err := r.client.Apps.GetByName(ctx, id) |
There was a problem hiding this comment.
why do we need separate GetByName call here? does not response already have the same type?
| AppName: id, | ||
| UpdateMask: updateMask, | ||
| } | ||
| updateWaiter, err := r.client.Apps.CreateUpdate(ctx, request) |
There was a problem hiding this comment.
Could it be possible that the only thing that changed is 'started' field, making this API call unnecessary?
| // localOnlyFields are AppState fields that have no counterpart in the remote state. | ||
| // They must not appear in the App update_mask. | ||
| var localOnlyFields = map[string]bool{ | ||
| "source_code_path": true, |
There was a problem hiding this comment.
Is it not available? I see source_code_path in https://docs.databricks.com/api/workspace/apps/get response under active_deployment.
| resources.alerts.*.id string ALL | ||
| resources.alerts.*.lifecycle resources.Lifecycle INPUT | ||
| resources.alerts.*.lifecycle.prevent_destroy bool INPUT | ||
| resources.alerts.*.lifecycle.started *bool INPUT |
There was a problem hiding this comment.
Question, should we have separate Lifecycle struct (LifecycleWithStarted) that has 'started' field so that the schema reflects which types support it?
There is a risk down the road of combinatorial explosion - we can revisit later if we end up there. From users' perspective (this schema, json schema, Python schema) I think it's best to have this type definition tight.
cc @pietern
Changes
Added support for lifecycle.started option
Why
This new option allows to start resources such as apps, clusters and sql warehouses in started/active state.
For apps: when this option enabled, on each bundle deploy we automatically will trigger a new app deploy
Tests
Added an acceptance test